IBIS Macromodel Task Group

Meeting date: 24 September 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Altair:                     * Junesang Lee
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:              * Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Dassault Systemes:            Longfei Bai
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              [Kinger Cai]
                              Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
                              Sai Zhou
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:               * Chulsoon Hwang
                            * Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Samsung:                      Jun-Bae Kim
Siemens EDA (Mentor):       * Arpad Muranyi
                              Randy Wolff
Signal Edge Solutions         Benjamin Dannan
Teraspeed Labs:               [Bob Ross]
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

Yifan:  Investigate with Arpad's SPICE circuit to see whether characteristics
        of rising and falling edges can help a model maker decide whether
        BIRD220.1 is applicable.
        - Done.  Yifan said she had an update to present.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the September 17th
meeting.  Michael moved to approve the minutes.  Dian seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD220.1 update:
Yifan reported on her investigation using the SPICE driver model provided by
Arpad.  She performed simulations with the model driving 50 Ohms to V_fixture
and swept V_fixture between Vcc and Vss.  She had duplicated the results
previously described by Arpad.  For V_fixture values between Vcc and Vss, the
edges of the rising and falling waveforms exhibited a plateau at V_fixture
during the transition.  The plateau corresponds to the period when neither
transistor is active, as the transistor turning off is shut off before the other
transistor is turned on, to minimize crowbar currents.

Yifan had set up a similar experiment with simple inverter chain pre-drivers for
the pullup and pulldown stages.  The pullup pre-driver stage consisted of 9
inverters, while the pulldown stage consisted of only 7.  Because of the
throughput delay skew between the two pre-driver stages, the output waveform
edges exhibited the same "plateau at V_fixture" effect.

Yifan concluded that testing with a V_fixture of Vdd/2 and looking for the
plateau behavior is a useful method for determining whether there is effectively
a single pre-driver path.  If the output edge(s) contain a plateau at V_fixture,
it implies that there are two distinct pre-driver paths.  If the plateaus are
seen, then it is likely that BIRD220.1's algorithm cannot be applied to the
device.

Arpad asked whether the lack of a plateau was enough to indicate that BIRD220.1
could be applied.  For example, if a device has two distinct pre-driver stages,
but the delay difference is small, then plateaus would not be seen.  Would
BIRD220.1 work properly in that case?  Yifan and Chulsoon said they believed
that it would work in that case, but Yifan said she would investigate this
question further.

Ts4file and [Ramp]:
Michael reviewed some new proposed language regarding Ts4file and Ramp, which
was an extension of the language used in [External Model].  Michael asked
whether it would help to introduce a new "bandwidth" keyword and drop the
requirement for [Ramp].  We would no longer have to worry about crosschecking
[Ramp] in that case.  Arpad said he might be sympathetic to that idea, but he
would have to discuss the ramifications with his development colleagues.

Walter said we know what edge rate means, it's the edge rate expected from this
device into a certain load.  We already have [Ramp] to provide that, and we can
say it's a "first-order estimate of driver switching characteristics" in the
cases where we have newer or better modeling information available ([External
Model], Ts4file).  Michael observed that even if we add a new "bandwidth"
keyword, it doesn't solve any of our problems if the data it contains is not
consistent with other keywords.  Arpad asked whether Michael was suggesting the
new keyword should provide data in the same ballpark as Ts4file with a given
stimulus, or I-V and V-t tables, etc.  If the keyword is just there to help
tools make initial set-up decisions or crosstalk simulation decisions, does it
have to be strictly checked against the other keywords?

Michael said a naive model maker might be creating a Ts4file model for AMI, but
they get warnings about [Ramp] not matching I-V tables.  So, they might just
twiddle their [Ramp] values to make the warnings go away.  Walter said he would
complain to the model maker in this case for producing a bad model.  He said
that a user or tool can sanity check the [Ramp] data.  If someone gives you a
model with a [Ramp] dt of 1ps when it should really be about 100ps, then shame
on the model maker.  Arpad said he would take the [Ramp] value with a grain of
salt in that case and use the new keyword (e.g., Ts4file) to come up with a
better first-order estimate.

Michael asked whether consensus was that we don't need a new keyword, and [Ramp]
should be consistent with I-V and with newer keywords.  Arpad said he didn't
think that was the consensus.  He thought the benefit of a new keyword was that
a model maker could use it to provide bandwidth information, and then they
wouldn't have to include [Ramp] and worry about the confusing crosschecks.

Walter said there are two philosophies on the parser.  One is that it is just a
syntax check and not responsible for quality of the data.  The second is that
even if it does quality checking it can't catch everything.  Sometimes garbage-
in garbage-out.  Walter noted that we don't currently check [Ramp] dt vs. the
V-t waveforms.  Why should we now worry about checking it vs. the Ts4file?  He
said if a model maker put a bad [Ramp] value in the model, the user could run a
step-response simulation, see that it doesn't match the dt value, and complain
to the model maker.  Michael asked what the simulation consequences might be.
Walter said you might get bad run-time performance of the simulation if the
initial step size is wrong because of a bad dt value, or your crosstalk scan
results may be invalid because you're saturating improperly.

Arpad suggested that we might add new subparameters to [Ramp] to specify the
loads matching the waveform loads.  If we did that and added two sets of dt
values for rising and two sets for falling, then we could have [Ramp] data for
test cases analogous to the rising/falling waveforms.  The parser could then
test the [Ramp] dt against the rising/falling V-t tables.  Michael asked whether
adding this new information to [Ramp] would add any useful data about the
buffer.  He said the principal point was still the same in his mind.  If the
model provides extra data, it needs to be crosschecked against the other data
in the model.

Ambrish asked what the point of adding a new keyword would be.  He asked why we
couldn't just make [Ramp] serve the same purpose.  Arpad and Michael said the
issue with [Ramp] is that it's currently subject to some confusing cross-
checking (and lack of cross-checking) by the parser.  Ambrish suggested that we
could go through the specification and clear up any confusion and fix the
language.  Arpad noted that cross-checking could still be complicated for the
parser, for example vs. Ts4file, or even worse [External Model].  Michael said
today [Ramp] is only partially cross checked (dV vs. I-V tables), and even
that may happen in cases where it's likely irrelevant, for example when Ts4file
is provided.  The parser currently demands (checks) that [Ramp] is consistent
with I-V data (if it is provided), but when Ts4file appears, and it is supposed
to be used instead of the I-V data, then what should the parser check?

Ambrish suggested that we should remove any requirement to cross-check [Ramp]
data at all and state that it is only bandwidth information.  Michael said that
saying [Ramp] isn't required at all is one extreme.  He said the other extreme
is to say that if it's there it should be crosschecked against everything.
Arpad said it's currently hard to determine when [Ramp] is a fundamental part
of the model or just providing edge rate/bandwidth information.  If we had a new
keyword, then it could provide the bandwidth information.  [Ramp] could then be
made optional, with the understanding that if it's provided it will be cross-
checked.  Micheal asked whether we want simulation information (bandwidth
initial estimate) included in the buffer model.

- Michael: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

Yifan:  Further investigate the feasibility of using the plateau test to decide
        whether BIRD220.1 is applicable for a given device model.

-------------
Next meeting: 01 October 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
